1. Field of the Invention
This invention relates to communication systems and associated devices and more particularly to methods of providing secure connectivity between devices across a public network (i.e., internet) by creating a virtual network between these devices that utilizes public network devices and methods.
2. Description of the Related Art
A communication system generally includes multiple communication devices interconnected to each other in such a way that each device may be able to establish a communication path with another device within the communication system. The interconnection between devices may take the form of an interconnected set of sub-networks or subnets. A network can be made up of localized subnets, or can be extended to include multiple subnets to form an intranet. Further, multiple intranets can be extended to form an internet.
Devices within a network communicate with one another using packet-based protocols such as Internet Protocol (IP) and Transmission Control Protocol (TCP). Data to be transmitted over the network using TCP/IP is broken up into a number of packets, which are transferred over the network along with embedded address and control information within each IP packet. These IP packets are separately sent across the network, possibly using different network paths, and are then re-assembled at a receiving device.
To ensure the reliability of the packet transmission, each layer of the popular Open System Interconnect (OSI) stack is responsible for a different aspect of transmission. The lower layers maintain the physical connection between devices while low-level protocols such as Ethernet provide a method for sharing the communication medium as well as encapsulating higher-layer packets such as IP.
The IP protocol provides a method for routing packets within and between intranets, and across logically separated network segments. It also includes methods for CRC error checking and fragmenting data into smaller frames depending on the maximum transmission unit (MTU) of the system. The Internet Protocol Version 4 (IPv4) specification provides for a 32-bit address field for packet source and destination, while the newer IPv6 specification expands this to 128 bits. The IP packet itself may encapsulate higher-layer communication protocols, such TCP, which can handle more advanced packet transmission functions such as out-of-order packet handling, communication timeouts and packet re-transmission.
A host is any device which can send and receive data and, as used herein, is generally found at the end nodes within a communications system. Each host will generally be capable of communicating using one or more of the protocols that are supported by the communication system, such as TCP/IP. Typical hosts include devices such as personal computers, printers and servers. Some devices, such as personal computers, have the ability to support more than one interface to a communications system. One example is a the use of multiple host network adapters within the same personal computer. In such a case, each interface can be considered a separate host within the communication system.
The communication between hosts within a network typically requires additional devices such as network switches and routers. A network switch allows more than one host to be connected to the same subnet, and allows those hosts to communicate with one another. A network switch will only allow for communication between devices that are members of the same subnet. A typical network switch will ignore TCP/IP information within each packet, and will only use lower-layer information to determine where to send each packet. In the case of TCP/IP over Ethernet, the Ethernet header will be used instead of the IP header to determine the packet source and destination. Each Ethernet interface that a host uses has a unique 48-bit Ethernet address. The Ethernet header contains both the source and destination Ethernet address, which are then used by the network switch to determine the packet destination.
A network router typically provides all of the functionality of a network switch, but additionally uses the information contained within the IP portion of the packet to allow hosts in different subnets to communicate with one another. An intranet, for example, may consist of multiple subnets, each with hosts that may need to communicate with hosts on other subnets. An intranet may also be connected to an internet using a network router. This would allow hosts within the intranet to communicate with hosts that are outside of their intranet.
The IP destination address is checked through the use of a lookup table within the router to determine if the destination for the packet is within the same subnet, or if the packet needs to be sent to a different subnet. If the router is connected to an internet, it can also use the IP destination address to determine if a packet should be routed between the internet and one of the subnets connected to the router.
In a distributed network environment such as an enterprise network, several intranets may be linked together through a public network such as the Internet. In many cases, the intranets are partitioned into smaller subnets to improve manageability and security. The subnets themselves may be logically partitioned further using virtual local area networks (VLANs). Network devices with VLAN functionality use IP address, Ethernet address and port number information to logically group network hosts together. This grouping can occur between hosts that are on different subnets, or even between hosts that are members of different intranets connected through an internet.
Although VLANs can be used to partition a network, they do little to provide network security. To secure the communications between hosts, a combination of security methods are used, including firewalls and virtual private networks (VPN).
Firewalls provide an intermediate stage where traffic to and from each switch or router can be monitored, translated and filtered as required. They are typically deployed at the entry/exit point of a network segment to filter access to and from the network segment. The problem with securing communication with firewalls is that they are designed to operate at a single point in the communication path. They do not monitor the complete communication path as a whole. This limited visibility prevents firewalls from being able to fully protect the entire communication path. In addition, they are difficult to configure because each firewall in the communication path must be updated and configured separately as security and accessibility needs change. Firewalls are also capable of disrupting or blocking higher-level communication protocols that are required for certain network services to function, and must be upgraded or modified to be compatible with these functions.
VPN provides a method of securing communication between hosts by encrypting communication between them. VPNs are typically deployed across a public internet to connect hosts together, and can also provide a method for securely connecting subnets together to form a secure intranet across a public internet. The VPN connection that is created across the public internet is called a VPN tunnel. One of the advantages of using VPN instead of a dedicated network is the reduced cost associated with using a public internet.
There are several ways of implementing VPN security. One method is to use Internet Protocol Security (IPsec) in tunnel mode, which encrypts IP packets and then encapsulates them in an additional IP header before sending them through a VPN tunnel. Authentication with IPsec typically uses IPsec internet key exchange (IKE) negotiation, which requires all hosts to authenticate before using the VPN tunnel. Although IPsec provides per-packet authentication, one disadvantage of most VPN implementations using IPsec is that authentication is based on the host using the VPN, rather than the user of the VPN connection. This would allow any user with access to the host to use the VPN. If IKE is not used, IPsec must assume that the VPN connection was authenticated before the VPN tunnel was created, which can be a large security loophole. Another limitation of IPsec is that it can't negotiate security for multicast or broadcast traffic, including Address Resolution Protocol (ARP) and Reverse Address Resolution Protocol (RARP). IPsec also has compatibility problems with peer-to-peer and real-time applications, as well as applications which use Internet Control Message Protocol (ICMP). Another disadvantage of IPsec is that the IPsec tunnel mode used in VPN applications does not support dynamic address assignment. Further, IPsec tunnel mode policies are not optimized for mobile clients with dynamic IP addresses.
Other methods of implementing VPN include the use of Point-to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol (L2TP). Both of these methods operate at the layer two data-link layer of the OSI stack, instead of layer three which IPsec uses. The advantage to using either of these two VPN implementations is that they both support IP, as well as IPX or NetBEUI traffic, while IPsec only supports IP. Another advantage is that PPTP and L2TP both support dynamic address assignment of hosts using the VPN. The L2TP is an open IETF standard, while PPTP is a proprietary implementation developed by Microsoft™, and so interoperability with non-Microsoft platforms can be difficult. Both PPTP and L2TP implementations encapsulate layer two Point-to-Point Protocol (PPP) datagrams and therefore inherit methods that are used by PPP, such as Extensible Authentication Protocol (EAP), which allows for “plug-in” modules to support new authentication schemes as they become available. One common EAP module is EAP Transport Layer Security (EAP-TLS), which uses public key certificates to provide user-level authentication.
An L2TP VPN implementation alone does not use cryptography to secure the VPN tunnel, and so L2TP must be combined with a protocol such as IPsec to provide a secure VPN connection. One method is to use the IPsec encapsulating security payload (ESP) to create a L2TP/IPsec VPN connection. The combination of L2TP and IPsec has been standardized as RFC3193. The combination of these two standards for VPN tunneling can be complex to maintain, and more seriously can be problematic with intermediate routing equipment, which may be inaccessible to those maintaining the VPN.
Another disadvantage to using L2TP/IPsec in a VPN implementation is that it is incompatible with network address translation (NAT) devices. These devices will not work with the Ipsec protocol unless Ipsec NAT Traversal (NAT-T) is used to encapsulate the Ipsec packet with a UDP or TCP header. The disadvantage to using NAT-T is that it may be implemented in different ways.
A PPTP VPN implementation also encapsulates PPP datagrams, but uses a TCP connection for VPN tunnel maintenance and uses generic routing encapsulation (GRE) to encapsulate PPP datagrams. This can be a serious problem with some routers, which block the GRE protocol. The PPP payload can be encrypted and/or compressed. Although PPTP provides per-packet data encryption, it does not provide per-packet data authentication, which IPsec provides. Another disadvantage of PPTP is that it does not provide per-packet data authentication, and so it cannot guarantee that a given packet was sent by the authorized user. It also cannot guarantee data integrity to assure that a packet was not modified in transit. Further, it only provides user level authentication, and does not provide authentication of the host itself.
Another VPN solution is to use an open standard called OpenVPN, which encapsulates IP/Ethernet packets and encrypts them using OpenSSL. As a security protocol, OpenSSL uses RSA public key cryptography, and is handled by the hosts at the application layer of the OSI stack. Although RSA public key cryptography is a robust form of security, it requires a high level of processing overhead resulting in increased latency for communications. Another factor affecting the performance of OpenVPN is that it has a high level of overhead in handling each packet. The IP/Ethernet packets are encapsulated in SSL and the SSL is further encapsulated in UDP/TCP.
As an alternative to using VPNs across a public network, a dedicated secure network (DSN) may be used. A DSN uses link-layer or physical-layer encryption devices to establish a secure network across a public network. The benefit of a DSN is that it has a lower impact on network performance than a VPN solution. However, DSNs are expensive to implement and maintain, and are not flexible enough for most deployments. They are also typically difficult to upgrade as new network or security capabilities are required.
The implementation of a secure enterprise network will often consist of a complex combination of network security methods that are used to secure both private subnets and connections between subnets, which traverse the Internet. In the case of a network such as that used in the financial industry, customers and remote ATM machines must be able to have a secure way to access account information across the Internet. Branch offices that can't use a DSN may need to use a VPN tunnel to connect their subnet(s) to a central office that performs their core-processing functions. Firewalls must be installed at the boundary and also within network segments for security, but these firewalls must be upgraded regularly as network policies change and as security loopholes are discovered. Further, there are often difficulties associated with making firewalls compatible with network security methods, or even with the communication itself. These compatibility problems often lead to security loopholes.
It would be desirable to have a method of creating a distributed secure virtual network of hosts that would be configurable so that individual hosts or groups of hosts could securely communicate across a public network using existing protocols such as IP, IPX, etc. The devices in this distributed secure virtual network should be configurable as to not to communicate with other terminating devices in the public network. Optionally, they should also be capable of communicating with other devices using a public protocol, but still communicate with the secure virtual network devices in a secure manner.
The distributed secure virtual network should be backward compatible with existing network devices, firewalls, NAT translation methods, and existing VPN solutions. When used as an alternative to VPN, it should provide a complete, stand-alone solution that is simple and inexpensive to install and administrate while providing advanced capabilities such as support for mobile and wireless hosts, secure ARP and RARP broadcasts, and secure dynamic address assignment of hosts.
Communication within the distributed secure virtual network should be secured and authenticated, with both host and user authentication. The security method used should be immune to decryption techniques and password attacks, and should dynamically change. Further, each secure virtual network should use a preventive form of security, which inherently provides security within its architecture, and therefore should not require upgrades to patch security problems over time.
The following patents are cited for background information only and are incorporated herein by reference: U.S. Pat. No. 6,154,839; U.S. Pat. No. 6,519,703; U.S. Pat. No. 6,883,098; U.S. Pat. No. 6,883,052; U.S. Pat. No. 6,877,041; U.S. Pat. No. 6,874,090; U.S. Pat. No. 6,785,728; U.S. Pat. No. 6,154,839; U.S. Pat. No. 6,519,703.